Individuals and companies today are increasingly reliant on information and commerce conducted over widely accessible electronic communications networks, such as the Internet. To be successful, a business engaged in electronic commerce with consumer-facing websites must ensure a high level of website performance under normal, as well as extreme traffic conditions. External events, such as a natural disaster, or certain calendar dates, such as the Super Bowl, Cyber-Monday, Tax Day, or Valentine's Day, can drive large numbers of users to a website, thus increasing the traffic load immensely. Many information technology systems begin to deny service, or fail to process message traffic efficiently, when communications traffic exceeds a processing capacity of the system. Such failures in communication can significantly impair the operations of an enterprise in many ways. For example, slower website performance is known to cause users/visitors to leave the website sooner. Another consequence of poor performance is that the website may be downgraded in search engine results rankings. A business enterprise can thus suffer losses in immediate and future sales, advertising revenue, and customer loyalty if their website responds in a slow manner—or worse, if the site crashes under the increased load.
In recent years, enterprises and developers have sought an easy and affordable way to use cloud computing as a way to load and performance test web sites and web-based applications. Cloud computing gets its name from the fact that the machine, storage, and application resources exist on a “cloud” of servers. In cloud computing shared resources, software and information are provided on-demand, like a public utility, via the Internet. Cloud computing is closely related to grid computing, which refers to the concept of interconnecting networked computers such that processing power, memory and data storage are all community resources that authorized users can utilize for specific tasks.
Load testing a web-based application or website typically involves simulating a very large number (e.g., up to or beyond 1,000,000) of virtual website users via Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) message intercommunications with the target website. By way of background, U.S. Pat. No. 7,844,036 describes a software tool which allows a user to efficiently compose and execute a message-based load test on a target website. The user is provided with a graphical user interface (GUI) that can be used to generate a test composition comprising a plurality of message clips organized into one or more tracks. Each clip typically includes a plurality of messages, with each track being organized into one or more bands. Each track and each band may run contemporaneously to send messages to a target device or application. In this manner, a user may create complex message streams containing thousands of messages that are played out according to a particular sequence, timing, and tempo to test the performance of a website.
One of the problems with existing load testing approaches is that when using a gateway application (commonly referred to as a gateway session) a token or value (also referred to as a property in the present application) is typically produced by the server associated with the target website. Such parametric values are commonly produced to authenticate the user. After the website server sends a token or value to a user, subsequent requests to the website need to send the same value or token back to the server to maintain communications.
Another difficulty that arises with generating a load test comprising thousands of virtual users is that the values sent from the target website to each user change dynamically. Values sent to each virtual user from a target website for each thread of execution need to be propagated or substituted back into subsequent messages communicated to the website in order to make the test run properly. If a wrong value is sent back to the target website, the load test will fail. In the past, this has necessitated a very tedious, error-prone, and labor-intensive process wherein a performance engineer is required to manually scan through a failed load test session recording to identify where in a message clip a particular value was received from a target website.